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PROVIDING A CAMEL BASED SERVICE TO A SUBCRIBER 
TERMINAL IN A WIN NETWORK AND VICE VERSA 



Field of the Invention 

The present invention relates to an interface (LEM) operative to provide 
a CAMEL based service to a subscriber terminal in a WIN network, a method of 
providing a CAMEL based service to a subscriber terminal in a WIN network, an 
5 interface (LEM) operative to provide a WIN based service to a subscriber terminal in a 
CAMEL network, and a method of providing a WIN based service to a subscriber 
terminal in a CAMEL network. 

Background of the Invention 

The value added service delivery mechanisms in present day circuit 

10 switched mobile networks are generally based on Intelligent Network (IN) techniques. 
In networks based on Global System for mobiles (GSM) or Universal Mobile 
Telecommunications System (UMTS) such IN type services are deployed using a 
standard known as Customized Application for Mobile Enhanced Logic CAMEL. In 
networks based on ANSI IS-41 such IN type services are deployed using a standard 

15 known as Wireless Intelligent Network WIN. The two protocols CAMEL and WIN are 
incompatible. This results in the fact that CAMEL Service Environment based services 
cannot be directly deployed in WIN based networks, and vice versa. Roaming mobile 
subscribers cannot be provided with the Operator Specific Services (OSS) while 
roaming in a network supporting an incompatible IN service protocol. 

20 Third Generation Wireless Networks are expected to enable the Mobile 

Internet to become a reality, offering fast Internet access and high-speed data services to 
mobile subscribers. In order for Network Operators to allow for the rapid development 
of innovative value added applications on the scale seen in the Internet today, the 
wireless core network needs to be opened up for third party applications provided by 

25 independent software vendors. The Third Generation Partnership Project (3GPP) is 
currently working on the production of technical specifications to provide a mechanism 
that would permit independent software vendors a standard interface to access network 
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capabilities traditionally available to network operators themselves. Within 3GPP, this 
mechanism is commonly referred to as the Open Service Access (OSA). This Open 
Service Access is predominantly targeted at UMTS (Universal Mobile 
Telecommunications Networks) networks, allowing application developers to access the 
5 feature-rich core network capabilities. 

The success of new service provision and deHvery platforms may depend 
on their ability to blend with existing technologies, offering programmability of service 
platform elements including network nodes, control nodes, and gateways, while in the 
mean time preserving the integrity of the underlying network equipment. An approach 
10 that has been demonstrated by various industry initiatives such as Parlay is to develop a 
set of open network Application Programming Interfaces (APIs) that offer this kind of 
programmability and integrity. Allowing rapid development of applications is achieved 
by opening up the network in such a way that application developers are not required to 
have extensive knowledge of the complexity of the network signalling. Telephony 
15 signalling protocols are relatively complex and the development of new services for 
example based on Intelligent Networks requires the skill knowledge of Intelligent 
Network Application Protocol (INAP) and the Transactions Capability Apphcations 
Part (TCAP). An architecture, based on the output from the Parlay Group is known 
within 3GPP specifications as the Open Service Access (OSA). The Open Service 
20 Access provides application developers with an abstraction of the functionality that 
resides within the core network. The abstraction is obtained be defining the core 
network functionality in terms of what is referred to as Service Capability Features 
(SCFs) which should be considered as technology independent building blocks that are 
accessible via standardized interfaces. They represent the basic functionality that is 
25 available within the network. Examples of Service Capability Features include Call 
Control, User Location and User Interaction and are supported in a network operator's 
domain through Service Capability Servers (SCS). The User Interaction Service 
Capability Feature can, for instance be supported on a WAP Gateway (WGW) or on the 
Home Location Register (HLR) while the Call Control Service Capability Feature can 
30 be supported by the CAMEL Service Environment (CSE). The applications themselves 
are executed on Application Servers, which may reside outside or inside the Network 
Operator domain. The Service Logic of the applications running on the Application 
Server is executed towards the Open Service Access interface, whereas the Service 
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Capability Servers use propriety protocols to communicate with the network nodes. The 
Open Service Access concept is shown in Figure 1 which shows the relationship 
between the network nodes, service capability servers (SCS), service capability features 
(SCF) and the third party application servers. Open Service Access is specified by the 
5 Third Generation Project Partnership, known as 3GPP. This organisation publishes 
specifications based on a phased release schedule, with each release providing 
additional functionality. The initial 3GPP UMTS set of specifications is referred to as 
Release 99. Subsequent releases are referred to as Release 4 and Release 5. For each 
release, a set of specifications is available for Open Service Access (OSA). 

10 

A known Open Service Access client application running on an Open 
Service Access Application Server (OSA AS) is shown in Figure 2 . The Open Service 
Access Gateway (OSA GW) has proprietary interfaces towards a CAMEL Service 
Environment (CSE), or CAMEL Service Control Point, and a WIN Service Control 
15 Point, as described in Third Generation Partnership Project Technical Specification 
23.127. Using this architecture, newly developed Open Service Access client 
applications can be deployed in both a WIN based 3G network, as well as in a CAMEL 
based 3G network. 

20 Known approaches to WEST/CAMEL interworking have relied on 

introducing a dedicated protocol converter between the mobile switching centre (MSG) 
in the GSM/UMTS network and the WIN platform and a protocol converter between the 
mobile switching centre (MSG) in the ASNI41/IS-95 network and the CSE. This is a 
complex and unwieldy approach. 



Summary of the Invention 

The present invention provides an interface (LEM) operative to provide a 
CAMEL based service to a subscriber terminal in a WIN network by causing the 
30 CAMEL based service to appear to the WIN network as an Application in accordance 
with the Open Service Access (OSA) standard. 
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Advantages of the present invention in its preferred embodiments are that 
a mechanism is provided for supporting legacy CAMEL Service Environment (CSE) 
based services in an IS-41 WIN based network.This achieves the aim of allowing 
CAMEL based services to be applied to network that only supports WIN. It is 
5 considerably cheaper than developing a 'legacy' protocol interface on the Call State 
Control Function (CSCF). Also, the approach serves as an overlay solution over 
standardized WIN and CAMEL core networks, i.e. there is no impact on the existing 
entities in the WIN and CAMEL networks.Also the Legacy Envelope Module approach 
is fully 3GPP/Parlay standards compliant. 

0 

Preferably the interface (LEM) comprises an Open Service Access 

(OS A) interface to an Open Service Access gateway (OS A GW) of the WIN network, 

and operative to convert received Open Service Access (OS A) messages to CAMEL 

Application Protocol Messages. 
5 Preferably CAMEL- based subscriber information is mapped to the WIN 

network, the interface acting as a WIN home location register (HLR). 

Preferably the interface is operative to pass the subscriber information by 

relating an Open Service Access (OSA) getNotification operation to a WEST registration 

notification (REGNOT) operation. 
0 Preferably upon a service request being made in respect of the subscriber 

terminal, a received Open Service Access (OSA) reportNotification is converted to a 

CAMEL Application. Protocol Initial Detection Point. 



The present invention also provides a mobile telecommunications system 
25 comprising a WIN network, the interface and the subscriber terminal, the subscriber 
terminal being a CAMEL subscriber terminal which has roamed into the WIN network. 



The present invention also provides a method of providing a CAMEL 
based service to a subscriber terminal in a WIN network comprising providing an 
30 interface (LEM) causing the CAMEL based service to appear to the WIN network as an 
Application in accordance with the Open Service Access (OSA) standard. 
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The present invention also provides an interface (LEM) operative to 
provide a WIN based service to a subscriber terniinal in a CAMEL network by causing 
the WIN based service to appear to the CAMEL network as a CAMEL apphcation 
(CAP). 

5 Preferably the interface comprises a WIN interface to a WIN platform of 

the WIN network, and operative to translate CAMEL Application Protocol messages to 
the WIN platform. 

Furthermore, the present invention also provides a mobile 
telecommunications system comprising a CAMEL network, the interface and the 
10 subscriber terminal, the subscriber terminal being a WIN subscriber terminal which has 
roamed into the CAMEL network. 

The present invention also provides a method of providing a WIN based 
service to a subscriber terminal in a CAMEL network comprising providing an interface 
15 (LEM) causing the WIN based service to appear to the CAMEL network as a CAMEL 
application (CAP). 

Brief Description of the Drawings 

A preferred embodiment of the present invention will now be described 
20 by way of example and with reference to the drawings, in which: 

Figure 1 is a diagrammatic illustration of Open Service Access 
architecture (prior art). 

Figure 2 is a diagrammatic illustration of Open Service Access 
Application deployed in both WIN and CAMEL network (prior art), 
25 Figure 3 is a diagrammatic illustration of Legacy CAMEL Service 

Environment Services deUvered to a CAMEL subscriber roaming in a WIN 
(ANSI41/IS95)network, 

Figure 4 is a diagranmiatic illustration of how a Trigger profile is set up 
for service provisioning to the CAMEL subscriber shown in Figure 3, 
30 Figure 5 is a diagrammatic illustration of CAMEL Service Environment 

Service invocation in a WIN network, and 



Bunting 2-5-4-3 - 6 - 

Figure 6 is a diagrammatic illustration of service delivered to a WIN 
subscriber roaming in a CAMEL network. 

Detailed Description 

5 

CAMEL subscriber in a WIN network 

Referring back to Figure 1 which showed how new applications could be 
deployed in both WIN and CAMEL networks using the Open Service Access (OSA), 
the question arises how can an existing i.e. legacy CAMEL Service Environment based 

10 (CSE) application be deployed in a WIN network? This question is relevant to network 
operators operating both types of networks, while looking for reuse of existing service 
logic for economic reasons. The question is also applicable to CAMEL subscribers 
roaming into a WIN network where they would still wish to have their CAMEL based 
Operator Specific Services 's at their disposal. 

15 Figure 3 shows a preferred system architecture whereby a GSM/UMTS 

subscriber roaming in an ANSI41/IS 95 network (with appropriate terminal) can have 
access to his/her CAMEL services. In the UMTS/GSM network, the Legacy Envelope 
Module LEM has a CAMEL Application Protocol interface to the CAMEL Service 
Environment as well as to the Mobile Switching Centres (MSCs) in the network. From 

20 the CSE perspective, the Legacy Envelope Module LEM acts as a switching platform 
(ie an MSC), while from the MSC perspective, the Legacy Envelope Module LEM acts 
as a service logic running on the equivalent of a CSE. 

In the ANSI41/IS95 network, the Legacy Envelope Module LEM has an 
Open Service Access (OSA) interface to the OSA gateway (GW). The OSA gateway 

25 (and hence the underlying network) see the Legacy Envelope Module LEM as an 

application platform providing a particular service. The Legacy Envelope Module LEM 
accepts Open Service Access (OSA) requests from the ANS1-41/IS95 network through 
the WIN interface. It then converts the Open Service Access (OSA) messages to 
CAMEL Application Protocol messages and sends them to the CSE that it associated 

30 with the subscriber. The CSE receives the service request in the same manner as it 

would if it had received the request from an mobile switching centre MSC in a GSM or 
UMTS network. It processes the request as a normal service invocation. The CAMEL 
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Service Environment (CSE) is unchanged (indeed unaware) of this signalling 
conversion. 

This conversion is achieved without dedicated WIN/CAMEL inter 
working function. A subscriber's CAMEL services reside and are executed on a per call 
5 basis in the CSE of the home network (this is always the case with CAMEL). In the 
normal case, the roamed to network needs to support the same version of CAMEL. The 
Legacy Envelope Module LEM was originally proposed as a mechanism to allow 
subscribers in the IP Multimedia Subsystem (IMS) to have access to CAMEL based 
services. Specifically as an emulator causing legacy services to appear to be Application 
10 Programming Interface (API) based. The scope of the Legacy Envelope Module LEM is 
now extended to allow WIN/CAMEL interworking. 

The approach proposed is that WIN/CAMEL inter-working is introduced 
with Open Service Access (OSA) as being the common medium. There is thus no 
dedicated function that maps WIN to mobile application part (MAP) (and vice versa). 
15 As operators will most likely deploy an Open Service Access (OSA) gateway in WIN 
networks, the Legacy Envelope Module LEM can be considered an enhanced version 
GSM/UMTS Open Service Access (OSA) advantageously re-using infrastructure. 

This mechanism for supporting legacy CAMEL Service Environment 
(CSE) based services in an IS-41 WIN based network will now be described in more 
20 detail. 

As shown in Figure 4, the calling party is a CAMEL subscriber, roaming 
in a WIN network, whose CAMEL trigger profile information is sent to its serving WIN 
system upon registration. The trigger profile is a collection of information held on a per- 
subcriber basis which indicates when value-added services are to be activated. If an 

25 incoming or outgoing call matches the trigger profile then a service is invoked, i.e. the 
"trigger" is "fired". As explained in more detail below the CAMEL trigger information 
is carried to the WIN domain using the Open Service Access method invocation 
getNotification. The Legacy Envelope Module LEM performs a mapping from an Open 
Service Access getNotification operation to the trigger profile in the WIN REGNOT 

30 protocol operation, where REGNOT is the registration notification message used in 

WIN to report the location of the subscriber and optionally to obtain and validate trigger 
information for that subscriber. This profile will cause a WIN trigger to be armed in the 
WIN Originating-Basic Call State Model (O-BCSM). This trigger causes the MSCAVIN 
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Service Switching Function (SSF) to launch a WIN query (ORREQ) during call setup 
[WIN Interim Standard IS-771]. 

Referring to the numbered steps shown in Figure 4, the messaging 
sequence is as follows: 

1 . The CAMEL subscriber roams into a WIN network and registers with the serving 
mobile switching centre (MSG). The serving WIN Service Switching Function will 
attempt to retrieve the subscribers WIN trigger profile by sending a WIN REGNOT 
operation to the visitor location register (VLR). This is normal behavior as specified 
in the WIN standard [WIN Interim Standard IS-771]. 

2. The visitor location register (VLR) will forward the WIN REGNOT operation to the 
Legacy Envelope Module (in normal operation the REGNOT is sent to the home 
location register (HLR) of the served subscriber). So the Legacy Envelope Module 
will act as a WIN home location register (HLR) towards the WIN visitor location 
register (VLR) on behalf of the CAMEL subscriber. 

3. The Legacy Envelope Module will map the WIN REGNOT to an Open Service 
Access getNotification method invocation. The semantics of the getNotification 
method are to retrieve the trigger profile information for the subscriber. To the Open 
Service Access Gateway, the Legacy Envelope Module will act as an Open Service 
Access Application Server. 

4. The Open Service Access Gateway will map the getNotification to the mobile 
application part (MAP) AnyTimelnterrogation to the home location register (HLR). 
This is normal behavior as specified in [3GPP Technical Specification TS 29.198 & 
3GPP Technical Report TR 29.998]. 

5. The home location register (HLR) will return the trigger profile in the mobile 
application part (MAP) AnyTimelnterrogation acknowledgement operation. This is 
normal behaviour as specified in the mobile application part (MAP) specification 
[3G Technical Specification TS 29.002]. 

6. The trigger profile returned in the ack to the AnyTimelnterrogation is carried in the 
out parameter for the Open Service Access method retum of getNotification. 

7. The Legacy Envelope Module will map the getNotification to the WIN regnot, 
which carries the trigger profile to the visitor location register (VLR). The WIN 
visitor location register (VLR) will think it received the regnot, carrying the trigger 
profile, from the WIN home location register (HLR) of the served subscriber. The 
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WIN visitor location register (VLR) will assume this is an ordinary WIN trigger 
profile, rather than a CAMEL trigger profile that is translated into a WIN trigger 
profile via Open Service Access (OSA). 

8. The visitor location register (VLR) will then forward the trigger profile in a WIN 
5 regnot to the serving MSCAVIN Service Switching Function. 

Note that there are at present no WIN protocol mapping 
recommendations in 3GPP Technical Report TR 29.998, but this is in line with the 
behaviour for CAMEL. As far as the Open Service Access Gateway in the home 
10 network is concerned, it sees no difference whether it was talking to an Open Service 
Access Application Server or the Legacy Envelope Module . As far as the WIN visitor 
location register (VLR) is concerned, it sees no difference whether it was talking to a 
WIN home location register (HLR) or the Legacy Envelope Module. 

15 Referring to Figure 5, the messaging sequence in invoking a service is as 

follows: 

1. A mobile originated call attempt by the CAMEL subscriber roaming in a WIN 
network will cause the MSCAVIN Service Switching Function to launch a WIN 
query (ORREQ) during call setup [WIN Interim Standard IS-771]. The WIN trigger 

20 will fire, since there is a WIN trigger profile loaded according to the scenario 

described in 3GPP Technical Specification Technical Specification TS 29.198 and 
3GPP Technical Report TR 29.998. The WIN ORREQ will be sent to the Open 
Service Access Gateway in the visited WIN network. Similar behaviour is described 
in the Open Service Access specifications [3G Technical Specification TS 29.198 & 

25 3G Technical Report TR 29.998] . Again, no WIN protocol mapping 

recommendations exist, but these would be expected to be very similar and 
analogous to the CAMEL mappings. 

2. The Open Service Access Gateway will map the WIN ORREQ to the Open Service 
Access reportNotification method invocation, very much like it would map the 

30 CAMEL Application Protocol Initial Detection Point to a reportNotification [3G 
Technical Report TR 29.998]. The Open Service Access reportNotification will be 
invoked on the Legacy Envelope Module , as if it were an Open Service Access 
Application Server. 
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3. The Legacy Envelope Module will map the Open Service Access reportNotification 
to the CAMEL Application Protocol Initial Detection Point, which will be sent to 
the CSE. For the CAMEL Service Environment it will appear as if the CAMEL 
Application Protocol Initial was received from an ordinary CAMEL Application 

5 Protocol Service Switching Function. The CAMEL Service Environment will 
perform its legacy CAMEL Service Environment service logic, which in this 
example consists of a number translation application. As a result, the CAMEL 
Service Environment will send a CAMEL Application Protocol Connect with the 
new routing information to the Legacy Envelope Module, as if it were the CAMEL 
10 Application Protocol Service Switching Function. 

4. The Legacy Envelope Module will map the CAMEL Application Protocol Connect 
to an Open Service Access routeReq method invocation to the Open Service Access 
Gateway. 

5. The Open Service Access Gateway will map the Open Service Access routeReq 
15 method to the WIN orreq protocol operation, similar to the mapping 

recommendations described in [3G Technical Report TR 29.998]. The WIN orreq 
will carry the routing information as it was determined by the legacy CAMEL 
service logic on the CSE. 

20 As far as the CAMEL Service Environment in the home network is 

concerned, it sees no difference whether it was talking to a CAMEL Service Switching 
Function (SSF) or the Legacy Envelope Module . As far as the Open Service Access 
Gateway in the visited network is concerned, it sees no difference whether it was talking 
to an Open Service Access Application Server or the Legacy Envelope Module. 

25 

WIN subscriber in a CAMEL network 

The principle can be extended to allow ANSI-41/IS-95 subscribers who 
roam into a GSM/UMTS network (with the appropriate terminal) and have access to 
their WIN based services. This is shown in Figure 6. In the ANSI-41/IS-95 network, the 
30 LEM has a WIN interface to a WIN platform. The WIN platform "sees" the LEM acting 
as a switching platform. The LEM has a CAMEL Application protocol (CAP) interface 
to the Mobile Switching Centres (MSCs) in the GSM/UMTS network as far as these 
MSCs are concerned, the LEM acts as a CAMEL based service platform. However, the 
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LEM provides the necessary translations between the GSM/UMTS MSCs and the WIN 
platform. The WIN platform is thus unaware that it is providing a service through a 
GSM/UMTS network. 

Also, many US operators are deploying GSM networks but still have 
5 WIN services that they could use. This proposal would also allow such operators to 
make continued provision of WIN services to GSM subscribers. 

Similarities between CAMEL and WIN 

10 Intelligent network capabilities are all those functional capabilities which 

support creation and execution of service logic programs which reside outside of 
switching equipment, but work in collaboration with the switching equipment based 
upon a common definition of call models and protocols [WIN Interim Standard IS-771]. 
The call model provides a high-level abstraction of a call that occurs in the network. 

15 This abstraction provides an observable view of the call in the Service Switching 

Function to the service capability feature (SCF), enabling the service capability feature 
(SCF) to interact with the Service Switching Function for execution of service logic. 
Both WIN and CAMEL define their own call models, but both are based on the 
International Telecommunications Union-Telecommunications Sector - Intelligent 

20 Networks call models defined in the ITU-T recommendation Q.1224. This section 
shows that the call models of WIN and CAMEL are sufficiently similar for the support 
of CAMEL services in a WIN network and vice versa. Only the Originating Basic Call 
State Models (O-BCSM) of the half call model are considered here. The O-BCSM for 
WIN is described in [WIN Interim Standards IS-771, IS-826, and IS-848] whereas the 

25 O-BCSM for CAMEL is described in [3G Technical Specification TS 23.078], 

CAMEL defines the following Detection Points associated with triggers: 
Analysedjnformation 
Route_Select_Failure 
30 - 0_Busy 

0_No_Answer 

0_Answer 

0_Disconnect 
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0_Abandon 

CAMEL defines the following Points in Call (PIC): 

- 0_Null & Authorise_Origination_Attempt_Collect_Info 

- Analyse_Information 
5 - Routing & Alerting 

0_Active 
0_Exception 

WIN defines the following Detection Points associated with triggers: 
10 - Origination_Attempt_Authorized 

- Collectedjnformation 
Analyzedjnformation 

- 0_Called_Party_Busy 
0_No_Answer 

15 - 0_Answer 

- 0_Disconnect 

WIN defines the following Point in Calls: 

- 0_Null 
Authorize_Origination_Attempt 

20 - Collect_Information 

- Analyze_Information 
Select_Route 

- Authorize_Call_Setup 

- Send_Call 
25 - 0_Alerting 

- 0_Active 
0_Suspended 

- 0_Exception 

30 The CAMEL Originating- Basic Call State Model is derived from Q- 

1224 by collapsing the Points in Call for which no Detection Points (DPs) are defined. 
The WIN Originating- Basic Call State Model O-BCSM is derived from Q.1224 by not 
defining triggers for every possible Detection Point. That means that although no one- 
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to-one mapping is obvious from the two Originating- Basic Call State Models, taking 
these modeling derivations into account we can identify the following common Points 
in Call and Detection Points: 

5 - Analyzed_Information 

- 0_Called_Party_Busy 
0_No_Answer 
0_Answer 

- 0_Disconnect 

10 

- 0_Null & Authorize_Origination_Attempt & Collect_Information 

- Analyze_Information 

- Routing & Alerting (Select_Route, Authorize_Call_Setup, Send_Call, 0_Alerting) 
0_Active 

15 - 0_Exception 

All CAMEL Points in Call are also supported by WIN, but CAMEL does 
not support all WIN Points In Call. Apart from Route_Select_Failure and 0_Abandon, 
all CAMEL Detection Points are supported. 
20 This analysis shows that most of the common CAMEL services, using 

the Originating- Basic Call State Model, can be supported. These include Number 
Translation 

OSA Support for th e CAMELAVIN Subset of Points in Call and Detection Points 
25 The previous section identified the commonalities between the call 

models of WIN and CAMEL. This section explores to what extend these models can be 
supported by the Open Service Access Application Programming Interface. We look at 
the support from event notification for the Detection Points only. 

30 - Analyzed_Information P_EVENT_GCCS_ADDRESS_ANALYSED_EVENT 

- 0_Called_Party_Busy P_CALL_REPORT_BUSY 

- 0_No_Answer P_CALL_REPORT_NO_ANSWER 
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- 0_Answer P_CALL_REPORT_ANSWER 

- 0_Disconnect P_CALL_REPORT_DISCONNECT 

This analysis shows that all event names at least can be transported 
5 across the Open Service Access Application Programming Interface. 

Some Points about Open Service Access Support 

Open Service Access (OSA) only provides support for address ranges as 

trigger criteria, whereas WIN trigger criteria includes e.g. Calling Party Information, 
10 Bearer Capability, and Class of Service. This is an inherent limitation of the Open 

Service Access Application Programming Interface and is not specific to this proposed 

Legacy Envelope Module approach. 

Of course as two protocol mappings are involved, e.g. from WIN to Open 

Service Access and from Open Service Access to CAMEL Application Protocol, with 
15 each mapping some level of detail may to be lost, as one-to-one mappings are not likely 

to be possible. Furthermore, each mapping stage introduces some processing delay. In 

this approach the processing delay is doubled in comparison with a straightforward 

Open Service Access approach. 
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